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Context-free  Grammars  and  Derivation  Trees  as  Programming  Tools 


Vollcer  Linnemann 

Computer  Systems  Research  Group 
University  of  Toronto 


Abstract 

It  is  shown  how  context-free  grammars  and  corresponding  derivation  trees  can  be  used 
by  application  programmers  if  adequate  language  tools  are  provided.  These  language 
tools  are  applicable  to  symbol  manipulation  problems,  especially  formula  manipula¬ 
tion,  and  to  program  generators.  They  have  the  remarkable  property  that  syntactical¬ 
ly  and  semantically  correct  programs  operate  only  on  syntactically  correct  derivation 
trees.  Implementation  issues  are  treated  in  an  appendix. 

Key  Words  :  BNF,  syntax-oriented  transformations,  symbol  manipulation, 
program  generators,  syntactical  correctness 
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1 .  Introduction  and  Notations 
1.1  Introduction 


This  paper  deals  with  language  tools  for  generating  and  manipulating  of  syntactical 
structures,  esp.  programs  written  in  high-level  languages.  In  order  Lo  show  what  is 
meant  by  this  two  small  problems  are  given  in  this  introduction  which  can  be  solved  in 
only  a  rather  cumbersome  way  by  using  conventional  programming  methods.  In  addi¬ 
tion,  conventional  programming  languages  do  not  aid  very  much  in  detecting  errors  as 
soon  as  possible,  i.e.  at  compile  -  time. 

Let  us  assume  we  have  a  very  simple  programming  language  which  contains  only  arith¬ 
metic  expressions  and  whose  syntax  is  given  as  follows 
(The  empty  word  is  denoted  by  a)  : 


<expr> 

:=  <expr>  4-  <term>  \  <term> 

<term> 

:=  <term>  *  <factor>  |  <factor> 

<factor> 

:=  <number>  j  <id>  j  (  <expr>  ) 

<number> 

:=  <digit>  <number>  |  <digit> 

<id> 

:=  <idhead>  <idtail> 

<idhead>  : 

=  <letter> 

<idtail> 

:=  <idtailel>  <idtail>  |  e 

<idtailel>  : 

=  <letter>  |  <digit> 

<letter> 

:=  a  j  b  |  c  {  ...  |  z 

<digit> 

:=0jl|2|3j4j5i6!7|8|9 

The  identifiers  <id>  in  this  language  denote  variables  which  contain  input  values.  The 
output  of  a  program  in  this  language  is  the  value  of  the  arithmetic  expression.  Now  let 
us  assume  we  want  to  write  a  program  which  reads  an  integer  value  n  and  produces  a 
program 

(  •  •  •  (aj^x  +  a^x  +  ao)*  ■  •  •  )*x+an), 

i.e.  we  want  to  write  a  very  simple  program  generator,  for  example  for  n  =  2  the  pro¬ 
gram  should  print  the  program 
((a0*x+al)*x+a2) 

Such  a  program  generator  could  be  written  in  ALGOL-68  (see  [6]  or  [18])  as  follows  : 
BEGIN 

INT  n;  read(n); 

TO  n  DO  print(  "("  )  OD; 
print("aO"); 

FOR  i  TO  n 
DO 

print((  "*x+a’\  i,  ")"  )) 

OD 

END 
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One  area  where  program  generators  are  required  is  the  area  ’Automatic  Programming’ 
where  programs  are  assembled  automatically  using  more  or  less  descriptive  state¬ 
ments  of  the  problem  to  be  solved  (see  Williams  [19]  ,  Manna  [12]  or  Goldberg  [2]  ). 

If  program  generators  are  written  in  such  a  straightforward  way,  the  following  disad¬ 
vantages  become  obvious  : 

a. )  The  programming  task  is  kind  of  awkward,  esp.  counting  the  brackets 
is  not  very  convenient. 

b. )  The  syntactical  correctness  of  the  generated  programs  is  not 
guaranteed,  for  example  if  we  replace  the  statement 

TO  n  DO  print(  ”("  )  OD 
by  the  statement 

TO  n-1  DO  print(  ”(”  )  OD 

the  program  remains  correct  as  far  as  the  language  specifications  for  ALGOL  -  68  are 
concerned,  i.e.  the  compiler  accepts  and  translates  the  program,  but  the  arithmetic 
expressions  which  can  be  generated  show  a  bracket  mismatch.  ALGOL-68  was  designed 
as  a  general-purpose  language.  If  you  wrant  to  design  a  special-purpose  language  for 
program  generation,  then  special  features  become  appropriate  such  that  the  syntacti¬ 
cal  correctness  of  all  generated  programs  can  already  be  checked  by  the  compiler 
which  compiles  the  program  generator.  As  far  as  the  example  is  concerned  this  means 
that  the  language  tools  do  not  allowr  writing  programs  which  generate  expressions  with 
a  bracket  mismatch.  This  paper  shall  show  how  such  language  tools  can  be  defined  by 
using  methods  from  the  theory  of  formal  languages. 

The  second  example  is  a  simple  formula  manipulation  problem.  Suppose  wTe  want  to 
write  a.  program  which  reads  an  arithmetic  expression  which  contains  the  variable  x. 
The  program  is  supposed  to  produce  the  formal  derivation  using  the  variable  x  con¬ 
forming  to  the  rules  of  usual  mathematics.  For  example  the  input 
x  *  x 

should  produce  the  output 
l*x  +  l*x 

If  we  try  to  write  a  program  for  this  problem  using  a  conventional  programming 
language  we  have  to  do  a  lot  of  programming  only  for  reading  the  expression,  checking 
it  and  transforming  into  an  appropriate  internal  form,  i.e.  we  have  to  write  a  parser 
manually.  In  order  to  avoid  this  additional  language  tools  shall  be  provided  in  the  sequ¬ 
el. 
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1.2  Notations 


In  this  chapter  the  basic  notations  are  collected. 

A  context-free  grammar  G  is  denoted  by 
G  =  (VN,  VT,  R,  <S>  ) 

■where  Vj v  is  a  nonempty  set  of  nonterminal  symbols, 

Vf  is  a  nonempty  set  of  terminal  symbols  disjoint  from  Vn. 

<S>  is  in  Vff,  called  start  -symbol, 

R  is  a  set  of  rules  of  the  form  <A>  ::=  a, 
where  <A>  e  V #  and  cr  e  {V^\jVj)* 

R  is  called  set  of  context-free  rules. 

The  empty  word  is  denoted  by  e. 

A  nonempty  word  a  over  V^\jVf  generates  directly  a  word 
{. 3  over  [J  Vj,  written  as  a  -»  (3,  iff 

cr  =  a{  <A  >  a2,  a2  e  (VN\jVT)*,  e  V}, 
f3  =  cr  a2,  where  the  rule  <A>  ::=  cr  is  in  R. 

The  relation  is  defined  as  the  reflexive,  transitive 
closure  of  a-*+£  is  the  transitive  closure  of  -»  . 

A  sequence  <S>  ->  cri  -»  •  ■  ■  -»  an  is  called  leftmost  derivation. 

Normally,  a  context-free  grammar  is  denoted  by  a  BACKUS-NAUR-System  (BNF  -  Sys¬ 
tem)  in  the  usual  way.  In  this  case,  the  start-symbol  is  the  nonterminal  symbol  on  the 
left  hand  side  of  the  first  production  and  several  alternatives  for  one  nonterminal  sym¬ 
bol  are  separated  by  "|"  . 

The  language  generated  by  a  context-free  grammar  G  is  defined  by 
L(G)  =  [<j\  <S>  ere  Vj]. 

The  notion  of  a  derivation  tree  is  defined  as  usual  (see  Aho, Ullman  [1]). 

We  say  a  grammar  G  is  reduced  iff 

a. )  for  each  <A>  e  V #  there  is  a  word  a  e  Vj  with  <A>  -**  a  ,  and 

b. )  for  each  <A>  c  Vj>/-j<S>j  there  are  words  a,  (3  c  (V#  such  that  <S>-»*  a  <A>  fS  . 

If  V  and  V'  are  alphabets,  a  simple  homomorphism  is  an  arbitrary  function 
h  :  V  -»  V*  . 

h  is  extended  to  a  function  h  :  7*  ->  V '*  by  the  following  definition  : 
h{a i  •  •  •  an)  =  h(at)  ■  ■  ■  MO 
h (e)  =  e  . 

If  R  is  the  set  of  context-free  rules  in  a  context-free  grammar  G  and 

h  :  Vf  -»  Vj  is  a  simple  homomorphism,  we  extend  h  to  Vj{jVjV  by  defining  h(<A>)  = 
<A>  for  all  <A>  e  V  jy  and  define 
h(R)  =  J  <A>  ::=  h(cr)  |  <A>  ::=  o  e  R  ],  and 
h(G)  =  (VN,  VT\  h(R).  <S>  ). 

If  S  is  an  arbitrary  finite  set,  the  number  of  elements  in  S  is  denoted  by  card(S). 
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2.  A  syntax-oriented  approach 


The  new  programming  tools  shall  be  explained  in  terms  of  the  simple  programming 
language  mentioned  in  the  introduction.  The  language  tools  shall  be  added  to  the  pro¬ 
gramming  language  ALGOL-68,  the  tools  can  be  defined  for  other  base  programming 
languages  which  allow  a  static  type  checking  in  a  similar  way. 

By  using  the  grammar  for  simple  arithmetic  expressions  mentioned  in  the  introduc¬ 
tion,  we  add  some  new  data  types  to  ALGOL-68.  The  new  types  and  the  corresponding 
values  are  summarized  in  the  following  table  : 


Type 

Values 

EXPR 

L(<expr>) 

TERM 

L(<term>) 

FACTOR 

L(<factor>) 

NUMBER 

L(<number>) 

ID 

L(<id>) 

ID  HEAD 

L(<idhead>) 

IDTAIL 

L(<idtail>) 

IDTAILEL 

L(<idtailel>) 

LETTER 

L(<letter>) 

DIGIT 

L(<digit>) 

That  means,  we  define  new  data  types  corresponding  one-to-one  to  the  nonterminal 
symbols  of  the  underlying  grammar.  Values  of  these  types  are  computed  by  a  language 
construction  called  generating  expression  ,  for  example  generating  expressions  for 
values  of  type  EXPR  look  like 
EXPRGEN  cr  NEG  . 

a  is  a  string  which  is  derivable  starting  with  the  nonterminal  <expr>  by  means  of  the 
underlying  grammar,  but  adequate  syntactical  positions  can  be  occupied  by  values  of 
the  new  data  tj'-pes,  separated  by  the  separators  \  and  $  .  For  example  the  following 
piece  of  program  contains  valid  generating  expressions  : 

EXPR  e;  TERM  t;co  a  variable  e  of  type  EXPR  and  a  variable  t  of 

type  TERM  are  declared  co 

e  :=  EXPR  GEN  x+y  NEG;  co  e  gets  the  expression  x+y  co 
t  :=  TERM  GEN  v*w  NEG;  co  t  gets  the  term  v*w  co 

e  :=  EXPRGEN  £e}  +a+b+  $t}  NEG  co  e  gets  the  expression  x+y+a+b+v*w  co 

In  order  to  define  formally  the  syntactical  positions  where  the  insertion  of  values  in 
generating  expressions  is  allowed,  we  augment  the  grammar  by  the  following  rules  : 
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<expr>  ::=  [EXPR} 

<term>  ::=  [TERMj 

<factor>  ::=  [FACTOR^ 

<idhead>  ::=  [ID} 

<idtailel>  ::=  [IDTAIL}  j  [ID} 

For  example  the  symbol  [EXPR}  stands  for  the  set  of  all  ALGOL-68  -  expressions  which 
deliver  a  value  of  type  EXPR,  enclosed  in  [  and  }  .  By  means  of  the  augmented  gram¬ 
mar  the  set  of  all  correct  generating  expressions  is  formally  defined.  We  shall  call  such 
a  grammar  a  generating  grammar.  In  addition  to  generating  expressions  we  introduce 
a  monadic  operator  idt  which  takes  INT  -  values  and  delivers  a  corresponding  IDTAIL  - 
value  by  computing  the  decimal  notation.  Using  these  tools,  we  can  solve  the  first  prob¬ 
lem  mentioned  in  the  introduction,  namely  generating  polynomial  expressions,  as  fol¬ 
lows  (  We  use  one  obvious  abbreviation  :  The  specification  of  the  type  of  a  generating 
expression  is  omitted  where  it  is  uniquely  defined  by  using  the  context,  for  example 
FACTOR  f  :=  GEN  aO  NEG 
stands  for 


FACTOR  f  :=  FACTOR  GEN  aO  NEG  ): 
BEGIN 

INT  n;  read(n); 

FACTOR  f  :=  GEN  aO  NEG; 

FOR  i  TO  n 


DO 

f  :=  GEN  (  [f}  *  x  +  a  [idt  i}  )  NEG 
OD; 

print(f) 

END  . 

It  is  obvious  that  only  correct  expressions  can  be  generated  if  the  new  language  tools 
are  used,  for  example  an  assignment 
f:=  GEN  (  [f}  *x+  a  [idt  i}  NEG 

is  syntactically  wrong  because  of  one  missing  bracket,  and  the  compiler  can  detect 
this  error.  Moreover,  parenthesis  -  structures  appear  always  statically  in  the  program 
generator  and  not  dynamically  as  in  the  solution  mentioned  in  the  introduction.  This 
avoids  bracket-  counting  and  enhances  readability.  Clearly,  the  concept  is  not  limited 
to  the  simple  expression  -  grammar,  generating  grammars  can  be  defined  for  "real" 
programming  languages.  Because  of  the  use  of  context-free  grammars,  the 
corresponding  parts  of  a  compiler  for  analyzing  and  translating  generating  expressions 
can  be  derived  automatically  by  using  conventional  compiler-compiler  techniques.  Ad¬ 
ditional  operators,  like  idt  in  the  example,  can  be  defined  by  special  statements  in  ad¬ 
dition  to  the  generating  grammar,  for  example  by 
COP  idt  =  INT,  STRING  TO  TDTATT,, 

which  means  that  the  operator  idt  should  convert  an  INT  -  or  STRING  -  input-value  to 
the  same  format  as  if  the  value  would  be  printed  (i.e.  decimal  notation),  check  whether 
it  is  derivable  starting  with  <idtail>  and  deliver  a  corresponding  IDTAIL  -  value.  The  im- 
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plementation  of  these  operators  can  be  derived  automatically  by  using  such  a 
definition.  Saying  it  in  another  way,  you  can  view  a  generating  grammar  and 
corresponding  COP-Declarations  as  a  new  way  of  defining  special  data  types. 


Now  let  us  turn  to  the  second  problem  mentioned  in  the  introduction.  We  generalize 
the  proposed  language  tools  for  program  generation  as  follows: 

1. )  The  corresponding  values  of  the  new  types  are  not  only  strings  but  derivation  trees 
corresponding  to  the  underlying  grammar;  that  means  strings  with  appropriate  syntac¬ 
tic  information.  The  generating  expressions  generate  derivation  trees  instead  of  simple 
strings,  and  if  a  value  of  a  new  data  type  is  read,  an  appropriate  derivation  tree  is  con¬ 
structed. 

2. )  In  order  to  work  with  these  trees  we  need  an  additional  tool  for  traversing  a  tree 
which  preserves  the  property  of  static  types.  This  tool  is  called  root  inspection  and  it 
shall  be  described,  by  means  of  examples  using  the  expression  grammar  from  the  intro¬ 
duction  : 

Assume  we  declare 
EXPR  e,e  1;  TERM  tl,t2; 

Then  the  expression 
ROOT  e  INTO  (elrtl,  t2) 
is  a  root  inspection,  and  it  works  as  follows  : 

The  input  tree  is  the  tree  stored  in  the  variable  e.  If  this  tree  is  a  tree 


<expr> 


<expr>  +  <term> 


i.e.  if  the  first  alternative  for  the  nonterminal  <expr>  is  used,  then  the  root  inspection 
delivers  the  INT  -  value  1,  el  gets  as  value  the  <expr>  -  subtree  on  the  left,  tl  gets  the 
<term>  -  subtree  on  the  right. 

If  the  tree  in  the  variable  e  is  a  tree 


<expr> 


<term> 


i.e.  if  the  second  alternative  for  the  nonterminal  <expr>  is  used,  the  root  inspection 
delivers  the  value  2  and  the  <tcrm>  -  subtree  is  put  into  the  variable  t2. 

Root  inspections  for  the  other  data  types  are  defined  in  a  similar  way. 

For  the  sake  of  simplicity  we  define  in  addition  to  root  inspections  a  dyadic  operator 
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top  .  This  operator  can  be  called  as  follows  : 
a  top  b  , 

where  a  delivers  a  variable  of  type  A,  b  delivers  a  value  of  type  B,  and  A  is  the  data  type 
which  corresponds  to  the  nonterminal  <A>,  B  is  the  data  type  which  corresponds  to  the 
nonterminal  <B>.  top  works  as  follows: 

a  top  b  delivers  the  boolean  value  TRUE  if  b  is  a  tree  which  corresponds  to  a  derivation 
<B  >  <A  >  ->*  a 

Tn  this  case,  the  subtree  which  corresponds  to  <4  >  -»*  cr  is  assigned  to  the  variable  a  (if 
several  trees  exist,  the  smallest  one  is  chosen).  If  b  doesn’t  satisfy  this  condition,  the 
boolean  value  FALSE  is  delivered  and  a  remains  unchanged. 

It  is  obvious  that  root  inspections  and  the  top  -  operator  can  be  used  for  traversing 
derivation  trees  and  that  derivation  trees  are  always  correct  corresponding  to  the 
underlying  grammar. 

The  problem  of  computing  the  formal  derivation  of  an  expression  mentioned  in  the  in¬ 
troduction  can  now  be  solved  as  follows  : 

BEGIN 

PROC  exprderivation  =  (EXPR  e  l)  EXPR  : 

BEGIN 

EXPR  e;  TERM  t; 

CASE 

ROOT  el  INTO  (e:t,t) 

IN 

GEN  [exprderivation(e)}  +  £termderivation(t)$  NEG  , 

GEN  [termderivation(t)]  NEG 
ESAC 
END; 

PROC  termderivation  =  (TERM  tl)  TERM  : 

BEGIN 

TERM  t;  FACTOR  f; 

CASE 

ROOT  tl  INTO  (t:f,f) 

IN 

GEN  (  jtermderivation(t)]  *  [f]  + 

[factorderivation(f)^  *  <(t^  ) 

NEG, 

GEN  ^factor derivation(f)}  NEG 
ESAC 
END; 
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OP  cfactor  =  (EXPR  e)  FACTOR  : 

BEGIN 

co  cfactor  puts  brackets  around  e  if  e  isn’t  already  a  factor  co 
FACTOR  f; 

IF 

f  top  e 

THEN 

f 

ELSE 

GEN  (  \e]  )  NEG 
FI 
END; 

PROC  factorderivation  =  (FACTOR  fl)  FACTOR  : 

BEGIN 
EXPR  e; 

CASE 

ROOT  fl  INTO  (  ,  ,  e) 

IN 

GEN  0  NEG, 

IF  fl  =  "x"  THEN  GEN  1  NEG  ELSE  GEN  0  NEG  FI, 

cfactor  (exprderivation(e)) 

ESAC 

END; 

co  Mainprogram  co 
EXPR  e;  read(e); 
e  :=  exprderivation(e); 
print(e) 

END 

This  example  shows  how  to  combine  generating  expressions  and  root  inspections  :  The 
root  inspections  analyze  the  tree,  and  the  generating  expressions  use  this  information 
for  generating  another  tree.  It  is  important  that  the  compiler  can  do  many  checks  very 
easily,  due  to  the  static  types  it  can  guarantee  that  the  program  wTorks  only  -with 
correct  trees  corresponding  to  the  underlying  grammar,  no  runtime  checks  are  re¬ 
quired  for  example  to  check  how  many  subtrees  a  tree  has  or  how  the  root  of  the  tree 
is  labelled. 

In  this  chapter  the  basic  ideas  for  incorporating  context-free  grammars  and  derivation 
trees  into  high-level  languages  with  a  static  type  concept  have  been  introduced,  and  we 
have  shown  how  to  use  them  for  writing  program  generators.  In  the  next  chapter  we 
shall  improve  the  basic  notations  and  discuss  some  interesting  questions  from  a  more 
theoretical  point  of  view. 
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3.  Automatic  Operator-Insertion 


There  is  one  disadvantage  so  far  :  If  we  look  at  the  simple  expression-  generating- 
grammar  mentioned  in  2.,  we  realize  that  it  is  always  necessary  to  write  the  operator 
idt  in  order  to  transform  an  INT  -  value  into  the  corresponding  IBTAlL-value.  For  exam¬ 
ple,  the  following  piece  of  program  is  not  correct  : 

INT  k;  read(k); 

EXPR  e  :=  GEN  aO+bO  NEG; 

FOR  i  TO  k 
DO 

e  :=  GEN  \e\  +  a|i$  +  b[i]  NEG 
OD 

But  in  this  case  it  is  clear  and  unambiguous  that  the  operator  idt  has  to  be  inserted 
two  times  in  the  generating  expression  in  the  loop.  It  would  be  nice  if  the  job  of  insert¬ 
ing  those  operators  could  be  done  automatically,  thus  making  the  program  correct. 
Formally,  we  can  define  an  automatic  operator-insertion  by  augmenting  the  generating 
grammar  by  the  rule 

<idtailel>  ::=  £idt :  INT  ->  IDTAIL^ 

which  means  that  the  operator  idt  has  to  be  inserted  if  an  expression  of  type  INT  is 
written  in  the  appropriate  syntactical  position  within  a  generating  expression.  The  ag¬ 
gregate  £idt  :  INT  ->  IDTAILj  is  treated  as  one  special  terminal  symbol  in  the  grammar, 
symbols  like  that  are  called  operator-symbols.  The  following  natural  restriction  is  as¬ 
sumed  :  The  operator-symbol  and  the  type  of  the  input-value  determine  uniquely  the 
type  of  the  output  -value,  for  example  the  following  rules  are  not  allowed  together  : 

<idtailel>  ::=  \idt :  INT  ->  IDTAILj  j  \idt :  INT  ->  IDTAILEL} 

However,  according  to  the  rules  of  ALGOL-68  operators,  the  two  productions 

<idtailel>  ::=  \idt :  INT  ->  1DTAILJ  |  | idt  :  STRING  ->  IDTAILJ 

are  allowed  because  the  operator-symbol  and  the  input-type  determine  uniquely  the 
output-type.  A  generating  grammar  which  contains  operator-symbols  according  to  the 
restriction  is  called  generating  grammar  with  operator-insertion. 

However,  there  is  a  problem  if  we  have  several  different  operators  :  The  insertion- 
process  might  be  ambiguous,  for  example  if  we  want  to  have  another  operator  idtoctal 
which  deliveres  an  octal  notation  of  the  INT  -  value,  and  if  we  have  the  rules 

<idtailel>  ::=  fidt :  INT  ->  IDTAIL}  |  £idtoctal  :  TNT  ->  IDTAIL] 
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the  operator-insertion  is  ambiguous.  The  following  question  arises  :  Is  it  decidable 
whether  an  arbitrary  generating  grammar  with  operator-  insertion  allows  an  unambigu¬ 
ous  operator-insertion  ?  Before  we  answer  this  question,  another  application  of  au¬ 
tomatic  operator-insertion  shall  be  described.  Let  us  look  at  the  following  example  : 


EXPR  el,e2; 

el  :=  GEN  a+b  NEG; 

e2  :=  GEN  c  *  [el}  NEG; 

This  piece  of  program  is  wrong,  because  el  is  not  allowed  in  a  position  -where  a 
<factor>  is  required.  We  can  correct  this  by  writing  brackets  ; 

e2  :=  GEN  c  *  (  [el]  )  NEG;  . 

This  bracketing  can  be  done  automatically  by  means  of  an  operator  which  is  inserted 
by  the  compiler.  The  operator  which  has  to  be  inserted  could  be  the  operator  cfactor 
from  the  last  program  in  2. 

Now  let  us  turn  to  the  problem  of  whether  the  ambiguity  of  automatic  operator- 
insertion  is  decidable  if  a  general  generating-grammar  with  operator-insertion  is  as¬ 
sumed.  At  first  we  define  unambiguous  operator-  insertion  formally  : 

Def.  1.  : 

Assume  G  =  (Vn,Vt,R,  <S>)  is  a  reduced  generating  grammar  with  operator-insertion. 
Asume  V j  =  Vj\)Vj  where  Vfr\Vf  is  empty  and  V?  contains  all  operator-symbols  of 

the  form  [opi  :  INPUTi  ->  OUTPUT for  i  =  1 . r  if  there  are  r  operator-symbols. 

We  define  a  simple  homomorphism  h  as  foliowrs  : 
h(a)  =  a  for  a  e  Vf  , 

h(fop4  :  INPUTi  ->  OUTPUT^)  =  [ fNPIJT .L],  i  =  1,  ...,  r. 

Informally,  h  erases  all  operators  and  output  types  in  the  operator-symbols,  all  other 
symbols  remain  unchanged,  h  is  called  G-operator-eraser.  We  say  :  G  allows  an  unam¬ 
biguous  operator-insertion  iff  h  is  one-to-one  on  L(G) 


Example  :  Assume  G  is  given  by  the  grammar  : 


<expr> 

<term> 

<factor> 

<number> 

<id> 

<idhead> 

<idtail> 


=  <expr>  +  <term>  |  <term>  |  [EXPR} 

=  <term>  *  <factor>  |  <factor>  |  [TERM} 

=  <number>  j  <id>|  (  <expr>  )  |  [FACTOR} 
=  <digit>  <number>  j  <digit> 

=  <idhead>  <idtail> 

=  <letter>  |  [ID} 

=  <idtailel>  <idtail>  |  s 
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<idtailel>  ::=  <letter>  j  <digit>  j  [IDTAIL}  |  £ID}  j  [idt :  INT  ->  IDTAIL} 

<letter>  ::=  a  |  b  |  c  i  ...  |  z 

<digit>  ::=  0!lj2j3!4;5|6l?j8j9 

Obviously,  G  allows  an  unambiguous  operator-insertion  corresponding  to  Def.  1. 

But  if  we  add  for  example  the  production 

<idtailel>  ::=  jidtoctal  :  INT  ->  IDTAIL}  , 

the  operator-insertion  is  ambiguous;  formally  we  have  for  example  : 

h(  a[idt :  INT  ->  IDTAIL}  )  =  a$INT}  and 
h(  a[idtoctal  :  INT  ->  IDTAIL}  )  =  a|INT}  . 

where  h  is  the  G  -  operator-eraser.  Note  that  the  brackets  \  and  }  are  not  used  as  set 
brackets. 

The  following  theorem  is  easy  to  prove  : 

Theorem  1  : 

If  G  =  (Vn,Vt,R,  <S> )  is  a  reduced  generating  grammar  with  operator  insertion,  it  is 
not  decidable  whether  G  allows  an  unambiguous  operator-insertion. 

Proof : 

Assume  and  L2  are  arbitrary  context-free  languages  without  operator  symbols,  and 
[idt :  INT  ->  IDTAIL}  and  ^idtoctal :  INT  ->  IDTAIL}  are  two  operator  symbols. 

Assume  G  ={Vs<Vt<^<  <S>)  is  a  reduced  generating  grammar 
with  operator  insertion  which  generates  the  language 
[idt :  INT  ->  IDTAIL}  L  x  \J  [idtoctal :  INT  ->  IDTAIL}  L2. 

Obviously,  G  allows  an  unambiguous  operator  insertion  if  and  only  if  L\C\L2  is  empty. 
Since  the  question  of  whether  two  arbitrary  context-free  languages  have  no  element  in 
common  is  not  decidable  (see  for  ex.  Salomaa  [14]),  theorem  1  is  proven. 

Fortunately,  the  following  decidable  criterion  can  be  proven  : 

Criterion  1  : 

If  G  =  (Vtf,VT,R,  <S  >)  is  a  reduced  generating  grammar  with  operator  insertion,  and  if  h 
is  the  G-operator-eraser,  the  following  statement  holds  : 
h(G)  is  LR(k)  for  a  particular  k  and  card(R)  =  card(h(R))  -> 

G  allows  an  unambiguous  operator-insertion. 

Proof : 

Assume  the  contrary,  i.e.  there  exists  a  cr  e  h(L(G))  such  that  there  are 
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a,  (3  e  L(G),  a  *  /S,  and  h(a)=h(£)=ar. 

That  means  that  we  have  two  different  leftmost  derivations 
<,S">  ->*  a  and  <S  >  ->*  (3  corresponding  to  R. 

Because  of  card(R)=card(h(R))  there  exists  a  one-to-one  correspondance  between  R 
and  h(R).  Therefore,  because  of 
h(a)  =  h(/S)  =  or  , 
the  derivations 

<£■>  -»*  h(a)  and  <S  >  ->*  h  (/?) 

represent  two  different  leftmost  derivations  for  cr,  i.e.  G  is  not  LR(k),  a  contradiction. 
Remark  : 

We  made  the  assumption  that  the  underlying  generating  grammar  is  reduced,  because 
if  the  grammar  is  not  reduced  there  may  be  parts  which  are  not  reachable  by  starting 
with  the  start  symbol  which  violate  unambiguous  operator-insertion  although  the  for¬ 
mal  definition  (without  the  reduce  -  requirement)  holds.  If  the  underlying  grammar 
does  not  satisfy  the  second  requirement  for  reduced  grammars  (see  definition  in  1.2), 
and  an  example  later  on  shall  show  where  this  might  happen, a  very  simple  technique 
can  be  applied  in  order  to  obtain  a  reduced  grammar  which  behaves  almost  the  same 
as  the  original  one  : 

Create  a  new  start  symbol  <S’>,  new  terminal  symbols  alp...,an  and  augment  the  set  of 

rules  by  the  rules 

<S’>  ::=  at<At>  |  •  |  an<An> 

where  the  set  of  nonterminal  symbols  is  VN  =  \<A  <An>\. 

Now,  Def.  1,  Theorem  1  and  Criterion  1  can  be  changed  to  the  case  where  the  underly¬ 
ing  grammar  does  not  satisfy  the  second  requirement  for  reduced  grammars:  just  take 
the  changed  grammar  mentioned  above  instead  of  the  original  one.  The  changes  are 
straightforward  and  left  to  the  reader. 

Now  the  last  remaining  question  is  :  How  can  we  define  the  meaning  of  the  operators 
which  are  supposed  to  be  inserted  automatically  ?  This  is  quite  straightforward  :  The 
operators  are  defined  in  a  special  ALGOL-68-  program  which  uses  the  language  tools 
described  so  far  (new  data  types,  ROOT  -  inspections,  top  -  operator).  The  underlying 
grammar  for  the  ROOT  -  inspections  and  the  top  -  operator  is  constructed  from  an 
underlying  generating  grammar  G  with  operator-insertion  as  follows  : 

The  symbols  [TYPE]  are  replaced  by  the  corresponding  nonterminal  symbol  <type>, 
the  operator-symbols  [op  :  INPUT  ->  OUTPUT]  are  replaced  the  nonterminal  <output> 
which  corresponds  to  OUTPUT,  useless  productions  of  the  form  <A>  ::=  <A>  are  re¬ 
moved.  This  grammar  is  called  tree  grammar  corresponding  to  G  because  it  defines  all 
possible  derivation  trees. 

Operators  which  define  a  conversion,  for-  ex.  idt  are  defined  by  a  COP  -  declaration  as 
mentioned  above. 
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4.  Examples 


1.)  The  generating  grammar  for  the  first  example  is  as  follows  : 


<expr> 

<term> 

<factor> 

<number> 

<id> 

<idhead> 

<idtail> 

<idtailel> 

<letter> 

<digit> 

<termh> 

<factorh> 


=  <term>  }  <expr>  +  <termh>  |  [EXPR} 

=  <factor>  i  <termh>  *  <factorh>  j  [TERM} 

=  <number>  j  <id>  |  (  <expr>  )  j  [FACTOR} 

=  <digit>  <number>  j  <digit>  ]  [den  :  INT  ->  NUMBER}]  [NUMBER} 

=  <idhead>  <idtail> 

=  <letter>  ]  [ID}  ]  [idf  :  STRING  ->  ID} 

=  <idtailel>  <idtail>  j  e 

=  <letter>  j  <digit>  j  [IDTAIL}  ]  [idt :  INT  ->  IDTAIL}  ] 

[idt  :  STRING  ->  IDTAIL} 

=  a  j  b  |  c  ]  ...  |  z 
=  0]  l|2|3]dr]5l  6!?i8]9 
=  <term>  j  [cterm  :  EXPR  ->  TERM} 

=  <factor>  |  [cfactor  :  EXPR  ->  FACTOR}  ]  [cfactor  :  TERM  ->  FACTOR} 


The  corresponding  tree  grammar  is  constructed  as  follows  : 


<expr> 

<term> 

<factor> 

<number> 

<id> 

<idhead> 

<  idt  ail  > 

<idtailel> 

<letter> 

<digit> 

<termh> 

<factorh> 


=  <term>  ]  <expr>  +  <termh> 

=  <fact.or>  ]  <termh>  *  <factorh> 
=  <number>  {  <id>  !  (  <expr>  ) 

=  <digit>  <number>  j  <digit> 

=  <idhead>  <idtail> 

=  <letter>  |  <id> 

=  <idtailel>  <idtail>  |  e 
=  <letter>  ]  <digit>  ]  <idtail> 

=  a  ]  b  |  c  j  ...  |  z 
=  0  |  1  |  2  j  3  ]  4  j  5  ]  6  ]  7  ]  8  j  9 
=  <term> 

=  <factor> 


Now  we  have  to  define  the  semantic  meaning  of  the  operators  by  defining  an  operator- 
program.  This  looks  like  this  : 

BEGIN 

COP  idt  =  INT,  STRING  TO  IDTAIL; 

COP  idf  =  STRING  TO  ID; 

COP  den  =  INT,  STRING  TO  NUMBER; 

OP  cterm  =  (EXPR  e)  TERM  : 

BEGIN 


TERM  t; 

IF  t  top  e 
THEN  t 

ELSE  GEN  (  [e}  )  NEG 
FI 
END; 
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OP  cfactor  -  (EXPR  e)  FACTOR  : 
BEGIN 
FACTOR  f; 

IF  f  top  e 
THEN  f 

ELSE  GEN  (  je|)  MEG 
FI 
END; 

OP  cfactor  =  (TERM  t)  FACTOR  : 
BEGIN 
FACTOR  f; 

IF  f  top  t 
THEN  f 

ELSE  GEN  (  ft])  NEG 
FI 
END 
END  . 


The  operators  cterm  and  cfactor  perform  a  conditional  automatic  bracketing,  they  put 
brackets  around  the  operand  only  if  it  doesn't  have  the  required  form.  Note  that  due  to 
the  automatic  bracketing  the  programmer  can  use  almost  everywhere  the  type  EXPR, 
there  is  no  need  to  use  the  types  TERM  or  FACTOR. 

The  problem  of  generating  polynomial  expressions  can  now  be  solved  this  way  : 

BEGIN 

INT  grad;  read(grad); 

EXPR  polynom  :=  GEN  aO  NEG; 

FOR  i  TO  grad 
DO 

polynom  :=  GEN  \ polynom  ]  *  x  +  afi]  NEG 
OD; 

print(polynom) 

END  . 

Due  to  the  automatic  operator-insertion,  the  generating  expression  in  the  FOR  -  loop  is 
equivalent  to 

polynom  :=  GEN  fctcrm  polynom]  *  x  +  afidt  i]  NEG. 

Therefore,  the  program  prints  for  example  for  n  =  3  the  string 
((a0*x+al)*x+a2)*x+a3 

£.)  The  next  example  gives  an  idea  of  how  to  construct  a  translator  using  the  tools 
described  so  far.  In  addition,  it  gives  an  example  where  the  underlying  grammar  is  not 
reduced.  Let  us  assume  we  want  to  write  a  translator  which  translates  a  simple  arith- 
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metic  expression  into  a  corresponding  program  for  a  stack  -  machine.  In  addition,  the 
translator  should  fold  constant  subexpressions  by  computing  the  value  at  compile¬ 
time.  We  augment  the  grammar  from  the  previous  example  by  the  following  rules  : 

<stackexpr>  ::=  <stackexpr>  <stackexpr>  <operator>J  LOAD  <id>  j  LOAD  <number>  | 

[fold  :  STACKEXPR  ->  STACKEXPR} 

<operator>  ::=  ADD  j  MULT 

The  operator  fold,  which  does  the  folding  of  constant  subexpressions  and  which  is  in¬ 
serted  automatically,  is  defined  as  follows,  the  procedure  compute  which  computes  the 
value  of  a  constant  subexpression  is  quite  straightforward  and  is  therefore  omitted: 

OP  fold  =  (STACKEXPR  e)  STACKEXPR  : 

BEGIN 

STACKEXPR  oprl,opr2;  OPERATOR  op;  ID  id;  NUMBER  number l,number2; 

IF 

ROOT  e  INTO  (oprl:opr2:op,  ,  )  =  1 

THEN 

IF  ROOT  oprl  INTO  (,  ,  numberl)  =  3  and 
ROOT  opr2  INTO  (,  ,  number2)  =  3 
THEN 

numberl  :=  compute(numberl,  number 2,  op); 

GEN  LOAD  [number  lj  NEG 
ELSE 
e 
FI 
ELSE 
e 
FI 
END 

Now  we  can  write  the  translator,  the  procedure  expr  is  the  solution  : 
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PROC  expr  =  (EXPR  el)  STACKEXPR  : 

BEGIN 

TERM  t;  EXPR  e;  TERMH  th;  STACKEXPR  s; 
CASE 

ROOT  el  INTO  (t.  e:th) 

IN 

s:=term(t), 

BEGIN 

ROOT  th  INTO  (t); 

s  :=  GEN  jexpr(e)}  [term(t)^  ADD  NEG 
END 
ESAC; 

GEN  [s]  NEG 
END; 

PROC  term  =  (TERM  tl)  STACKEXPR  : 

BEGIN 

FACTOR  f;  TERM  t;  TERMH  th;  FACTORH  fh; 
CASE 

ROOT  tl  INTO  (f,  th:fh) 

IN  ■ 

factor(f), 

BEGIN 

ROOT  th  INTO  (t);  ROOT  fh  INTO  (f); 

GEN  (term(t)j  |factor(f)j  MULT  NEG 
END 
ESAC 
END; 

PROC  factor  =  (FACTOR  fl)  STACKEXPR  ; 

BEGIN 

EXPR  e;  ID  id;  NUMBER  nu; 

CASE 

ROOT  fl  INTO  (nu,  id,  e) 

IN 

GEN  LOAD  \nu]  NEG, 

GEN  LOAD  jidj  NEG, 
expr(e) 

ESAC 
END  . 
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For  the  input  -  expression 
(2*3  +  c*d)  *  e 

expr  delivers  the  STACKEXPR  -  value 

LOAD  6 
LOAD  c 
LOAD  d 
MULT 
ADD 
LOAD  e 
MULT 

The  reader  should  verify  this  carefully,  especially  the  mechanism  of  folding. 

3.)  For  the  next  example  we  have  to  augment  our  simple  expression-programming- 
language  slightly.  We  augment  it  by  introducing  assignment  statements,  lists  of  state¬ 
ments,  indexed  variables  and  loops  as  follows  : 

<stmtlist>  ::=  <stmtlist>  ;  <stmt>  |  <stmt> 

<stmt>  ::=  <variable>  :=  <expr>  j  <expr>  j 


FOR  <id>  FROM  <expr>  BY  <expr>  TO  <expr>  DO  <stmtlist>  OD  | 
JSTMTLISTJ 


<variable>  ::=  <id>  |  <id>  [  <indexlist>  ] 

<indexlist>  ::=  <indcxlist>  ,  <indexlistel>  |  <indexlistel> 
<indexlistel>  ::=  <expr>  j  ^INDEXLIST} 


<expr> 


(  as  in  example  1.,  replace  <id>  by  <variable>  in  the  production 
for  <factor>  ) 


The  semantics  of  this  language  is  quite  straightforward:  the  output-value  of  a  program 
is  the  value  of  the  last  expression. 

Assume  we  want  a  program  generator  which  generates  a  program  for  evaluating  a  poly¬ 
nomial  expression 


1=o  i3-0  ik-0 


The  structure  of  the  generated  program  could  be  as  follows  : 
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hx  :=  0; 

FOR  i!  FROM  0  BY  lTOnj 
DO 

h2  :=  0; 

FOR  i2  FROM  0  BY  1  TO  n2 
DO 

ft 3  :=  0; 


FOR  4-i  FROM  0  BY  1  TO 
DO 

hk  :=  0; 

FOR  4  FROM  0  BY  1  TO  nk 
DO 

hk  :=  hk *1%  +a [ij,  .  .  .  ,4] 

OD; 

hk- 1  ’•=  hk-i*xt-i+hk 

OD; 


^ig  *  hz*x2^~h 3 

OD; 

/ii  :=  h{*X\+hz 
OD; 
hi 

The  program  generator  -works  as  follows  : 
BEGIN 

INDEXLIST  il;  STMTLIST  st;  INT  k;  read(k); 

co  generate  the  indexlist  i\,  ...  ,ik  co 
il  :=  GENU  NEG; 

FOR  j  FROM  2  TO  k 
DO 

il  :=  GEN  [ilj.ijjj  NEG 
OD; 
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co  generate  the  nested  loops  co 

st  :=  GEN  hfkj  :=  hfk^  *  xfk]  +  a[  filj  ]  NEG; 

FOR  j  FROM  k  BY  -1  TO  2 
DO 

st  :=  GEN 

:= 

FOR  if  j}  FROM  0  BY  1  TO  nf }] 

DO 

(st) 

OD; 

hfj-li  :=  hfj-lj  *  xfj-lj  +  hfjj 
NEG 
OD; 

st  :=  GEN 

hi  :=  0; 

FOR  il  FROM  0  BY  1  TO  hi 
DO 
1st] 

OD; 

hi 

NEG; 

print(st) 

END 

In  Linnemann  [9]  a  generating  grammar  with  operator-insertion  and  a  corresponding 
operator-program  for  ALGOL-83  are  given  thus  showing  that  the  tools  are  useful  not 
only  for  artificial  programming  languages  but  also  for  existing  ones. 

In  Linnemann  [11]  a  method  is  given  for  generating  lists,  for  example  lists  of 
identifiers,  in  a  more  descriptive  manner. 
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5.  Relations  to  other  works,  Conclusion 


Without  claiming  completeness,  some  other  works  related  to  this  paper  shall  be  dis¬ 
cussed  in  this  chapter.  At  first,  language  tools  for  program  generation  shall  be  looked 
at.  Perhaps  the  best  known  tools  are  the  "Compile-Time-Facilities"  provided  in  PL/1 
(see  Weinberg  [17]).  Although  they  were  developed  especially  for  generating  PL/1- 
programs,  they  can  be  used,  at  least  in  principle,  for  generating  programs  in  other 
languages.  The  problem  of  generating  polynomial  expressions  mentioned  in  the  intro¬ 
duction  could  be  solved  by  using  the  PL/1  Compile-Time-Facilities  in  the  following 
manner  : 

%DECLARE  (I,N)  FIXED; 

%N  =  <polynomdegree>; 

%D0  1=1  TON; 

( 

%END; 

aO 

%D0  1=1  TO  N; 

*x+a[I]) 

%END  . 

According  to  the  rules  of  PL/1  the  statements  starting  with  the  %  -  symbol  are  to  be  ex¬ 
ecuted  during  program  generation,  the  remaining  lines  denote  the  text  which  has  to  be 
generated. 

Of  course,  every  programming  language  which  allows  string-manipulation  (for  ex.  SNO- 
BOL  4,  see  Griswold  [3])  can  be  used  for  program  generation  and  for  decomposition  of 
strings  into  syntactic  components,  but  no  precautions  are  taken  in  order  to  guarantee 
that  only  syntactically  correct  programs  are  generated  and  that  the  program  works 
only  with  syntactically  correct  structures.  Beyond  that,  the  clarity  often  leaves  much 
to  be  desired. 

One  work  which  is  closely  related  to  the  topics  discussed  in  this  paper  is 
Maurer/Stucky  [13],  This  work  suggests  to  augment  conventional  programming 
languages  by  a  new  data  type  called  CEARTREE,  values  of  type  CHARTREE  are  deriva¬ 
tion  trees  corresponding  to  an  underlying  context-free  grammar,  the  label  of  the  root 
is  not  part  of  the  data  type.  We  shall  explain  the  notation  of  [13]  by  an  example.  The 
following  ALGOL-68  -  program,  augmented  by  the  tools  of  [13],  translates  an  arithmetic 
expression  to  a  corresponding  postfix -notation  : 
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BEGIN 

CHARTREE 

expr 

term 

factor 

number 

id 

letter 

digit 

co 


=  factor  v  term  factor, 

=  number  v  id  v  "("  expr 
=  digit  number  v  digit, 

=  id  letter  v  id  digit  v  letter, 


=  term  v  expr  ”+"  term, 


=  "a"  v  "b"  v  ...  v  ”z”, 
=  ”0”  v  ”1”  v  ...  v  ”9”; 


At  this  point  of  the  program  the  variables  expr,  term,  factor, 
number,  id,  letter,  digit  are  declared,  the  data  type  is 
CHARTREE,  and  the  derivation  trees  which  are  allowed  are 
given  by  the  corresponding  productions.  Terminal  symbols  are 
distinguished  from  nonterminal  symbols  by  ",  alternatives  are 
separated  by  v. 
co 

PROC  exprtranslation  =  (CHARTREE  el)  VOID  : 

BEGIN 

IF  el  alt  term 
THEN 

co  el  is  a  term  co 
termtranslation(e  l.term) 

ELSE 

IF  el  alt  expr”+Mterm 
THEN 

co  el  is  an  expr  +  term  co 
exprtranslation(el.expr); 
termtranslation(e  l.term); 
print((''ADD'\  newline)) 

ELSE 

print(”exprtranslation  has  an  illegal  argument”) 


FI 

FI 

END; 


co  term  translation  and  factor  translation  are  very  similar 
and  left  to  the  reader 


co 
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STRING  input;  CHARTREE  e; 
read(input); 

e  :=  input  co  this  assignment  generates  a  derivation  tree  co; 

IF  e  =  NIL 
THEN 

print(”input  is  syntactically  wrong") 

ELSE 

exprtranslation(e) 

FI 

END  .  ' 

The  operator  alt  obviously  corresponds  to  the  root-inspection  explained  in  2,  but  alt  is 
simpler  because  it  checks  only  which  alternative  has  been  used,  no  assignments  are 
performed.  The  subtrees  have  to  be  assigned  explicitly  by  using  for  example 
el.expr  or  el. term.  Because  there  is  only  one  new  data  type,  programming  is  not  as 
safe  as  it  is  if  the  tools  mentioned  in  2.)  are  used.  For  a  good  error  analysis,  many  run¬ 
time-checks  are  necessary,  for  example  expressions  like  el.expr  must  check  whether  a 
corresponding  subtree  exists.  These  checks  can  be  done  completely  at  compile-time  if 
the  tools  described  in  2.)  are  used. . 

Another  work  which  is  related  to  this  paper  is  Silverberg  [15].  He  tries  to  use  affix- 
grammars  (see  Koster[5]  or  Watt[l6])  as  the  basis  for  a  programming  language,  i.e.  he 
tries  to  augment  affix-grammars  by  actions  like  for  example  assignment  statements. 
We  want  to  explain  his  method  by  an  example.  Assume  we  want  to  handle  data-records, 
every  record  contains  a  unique  key  of  the  data  type  "Reckey",  and  information  of  data 
type  "Recinfo".  We  assume  that  the  keys  can  be  ordered,  and  that  the  records  are  or¬ 
dered  in  ascending  order.  We  want  to  perform  some  actions  for  each  record  by  using  a 
given  procedure  called  action  (key,  info).  The  sequence  of  records  is  terminated  by  a 
dummy  record  with  a  special  key  which  satisfies  the  condition  end  (key).  The  program 
which  does  the  actions  and  specifies  the  correct  data  structures  can  be  written,  ac¬ 
cording  to  Silverberg,  as  follows  : 

data  :  var  key  :  Reckey,  info  :  Recinfo; 

group(tkey);  list(-lkey);  record(tkey.tinfo)  . 
group(tkey)  ;  var  key  :  Reckey; 

record(tkey.tinfo);  action(ikey,linfo);  list(ikey)  . 
list(lkey)  :  var  newkey  :  Reckey; 

record(tnewkey.tinfo);  end(inewkey) 

V  record(tnewkey,tinfo);  key  <  newkey; 
action(lnewkey,Ainfo);  list(lnewkey)  . 

The  first  two  lines  define  data  types  and  names,  the  other  lines  are,  in  essence,  produc¬ 
tions  of  an  affix-grammar  according  to  the  terminology  of  Watt  [16],  where  inherited 
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affixes  are  called  input  parameters,  derived  affixes  are  called  output  parameters.  Input 
parameters  are  denoted  by  i  ,  output  parameters  by  t  .  The  notation  record{tkey, 
tinfo)  which  is  left  undefined  in  the  program,  deliveres  the  next  record  which  is  used  as 
an  input  to  the  procedure  action.  The  nonterminal  list  has  two  alternatives  which  are 
separated  by  the  symbol  V.  The  predicates  end(inewkey)  and  key  <  newkey  determine 
which  alternative  is  used.  These  predicates  are  the  primitive  predicates  in  Watt  [16].  If 
no  predicate  yields  true,  the  program  stops.  This  is  the  case  if  the  records  are  in  a 
wrong  order.  Silverberg  tries  to  augment  affix-grammars  by  actions  in  order  to  define 
all  correct  inputs  by  the  grammar  and  the  corresponding  actions  by  augmenting  the 
grammar.  Such  an  approach  frees  the  programmer  from  writing  a  parser  for  checking 
the  input-data.  The  productions  look  very  much  like  procedures,  but  it  remains  open 
how  errors  can  be  handled,  and  the  mechanism  is  not  deterministic.  The  main  ques¬ 
tions  of  uniqueness  and  determining  the  sequence  of  the  actions  are  unsolved.  The 
methods  for  traversing  derivation  trees  described  in  this  paper  and  Silverbergs  propo¬ 
sals  are  very  similar  if  procedures  are  used  and  one  procedure  is  assigned  to  each  non¬ 
terminal  of  the  underlying  context-free  grammar. 

Hopefully,  this  paper  has  shown  that  it  makes  sense  to  use  methods  from  the  theory  of 
formal  languages  in  order  to  provide  safe  programming  tools  by  using  static-type¬ 
checking  methods  for  writing  program  generators  and  programs  which  manipulate  syn¬ 
tactic  structures. 
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Appendix  :  Implementation  Issues 
Al .  Representation  of  Derivation  Trees 

It  is  obvious  that  the  implementation  of  generating  expressions  in  a  straightforward 
manner,  i.e.  copying  and  substitution  of  trees,  is  a  rather  slow  and  memory  consuming 
operation.  As  we  will  see,  this  can  be  avoided  by  using  pointers  and  by  using  subtrees  in 
a  recursive  manner.  Moreover,  it  is  obvious  that  the  labels  for  the  nodes,  i.e.  names  of 
nonterminal  and  terminal  symbols  can  be  omitted  because  this  information  is  not 
needed  at  run  time  because  it  is  statically  in  the  program.  Nodes  labelled  by  terminal 
symbols  can  be  omitted,  except,  of  course,  nodes  for  the  special  symbols  j  ...  ]  .  The 
internal  representation  of  derivation  trees  can  be  explained  by  using  ALGOL-68  modes 
as  follows,  the  modes  are  illustrated  by  an  example  later  on. 


=  STRUCT(  REF  []  CTREE  sons,  INT  pnr  ); 

=  UNI0N(  INT.  N0RMN0DE  ); 

=  STRUCT(  REF  GTREE  tree,  REF  []  SUBTREE  subtrees  ); 
=  SUBTREE 


MODE  N0RMN0DE 
MODE  GTREE 
MODE  SUBTREE 
MODE  A* 


where  the  A^s  are  the  new  data  types  corresponding  to  nonterminal  symbols  <A*>. 
These  modes  represent  derivation  trees  in  the  following  way  : 

MODE  GTREE  :  A  value  of  type  GTREE  represents  a  node  in  a  derivation  tree  as  follows  : 
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a. )  First  UNION  -  Alternative  : 

The  node  represents  a  special  symbol  of  the  form  £...}.  The  INT  -  value  is  the  index  by 
which  the  subtree  which  has  been  substituted  for  the  special  symbol  $...}  during  the 
evaluation  of  a  generating  expression  can  be  selected  out  of  a  corresponding  SUBTREE 
-  array  (see  later) 

b. )  Second  UNION  -  Alternative  : 

The  node  is  labelled  by  a  nonterminal  symbol,  the  NORMNODE  -  components  have  the 
following  meaning  : 

sons  :  pointer  to  an  array  where  the  sons  of  the  node  are  stored,  NIL  if  this  node  has  no 
sons  which  are  of  significance,  i.e.  it  has  either  no  sons  or  only  sons  which  are  labelled 
by  simple  terminal  symbols 

pnr  :  this  component  is  the  value  which  is  delivered  by  a  root  inspection. 

MODE  SUBTREE  : 

A  value  of  type  SUBTREE  represents  a  subtree  which  has  been  substituted  during  the 
evaluation  of  a  generating  expression,  such  a  subtree  can  be  reached  by  using  the  INT  - 
value  in  a  value  of  type  GTREE.  The  components  have  the  following  meaning  : 
tree  :  points  to  a  tree 

subtrees  :  points  to  an  array  where  pointers  have  been  stored  during  the  evaluation  of 
a  generating  expression,  NIL  if  no  pointers  exist. 

These  definitions  will  be  clarified  by  the  next  example  : 

Example  1  : 

The  underlying  grammar  is  the  grammar  from  the  first  example  from  chapter  4.  In  ad¬ 
dition,  we  assume  the  program  from  the  same  example  which  will  be  repeated  for  clari¬ 
ty  : 

BEGIN 

INT  grad;  read(grad); 

EXPR  polynom  :=  GEN  aO  NEG; 

FOR  i  TO  grad 
DO 

polynom  :=■  GEN  £  polynom}  *  x  +  a£i}  NEG 
OD; 

print(polynom) 

END  . 

The  generating  expression  in  the  loop  looks  like 
EXPR  GEN  jeterm  polynom}  *  x  +  ajidt  i}  NEG 
if  augmented  by  automatically  inserted  operators.  According  to  example  1  in  chapter 
4,  cterm  looks  like 
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OP  cterm  =  (EXPR  e)  TERM  : 
BEGIN 
TERM  t; 

IF  t  top  e 
THEN  t 

ELSE  GEN  (  \e]  )  NEG 
FI 

END  . 


The  translator  can  generate  corresponding  GTREE  -  objects  for  all  generating  expres¬ 
sions.  These  objects  are  the  following  structures,  where  UNION  -  alternatives  are  dis¬ 
tinguished  by  a  leading  bit.  The  labels  of  the  nodes  are  given  for  clarity,  they  are  not 
stored. 

1.)  EXPR  GEN  £ctercn  polynom]  *  x  +  a£idt  i^  NEG  : 


J"-1 

expr^> 

dfSD 

_ + < termh> 

I1  U 

1 

1 

<  term> 


h  1 

2 

>rh> 

<  termh*  ^  < facte 

Jij _ Li 

ITT 

1 

{ . . . }  <  f actor> 

L°i  1 

2 

<id> 


1 


J 


<idhead>  w 

< idtail> 

U4- 

1 

1 

LI 

NIL  2  } 

< ] ettor> 


1 

NIL)  24 

<  term> 


1  1 

1 

<  f actor> 

1  ] 

2 

<id> 

1 

1 

<idhead5 


1 

-Is 

ZJj 

1 

El 


NIL  1 


1 

1 

3 

1 

nil!  ? 

f . 

0 

2j 

2.)  TERM  GEN  (  \e]  )  NEG  : 

(This  tree  reflects  the  elimination  of  the  useless  production  <expr>  ::=  <expr>  ac¬ 
cording  to  the  definition  at  the  end  of  chapter  3.) 
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3.)  EXPR  GEN  at)  NEG  : 


QEED-. 


<e 

xpr  > 

'J 

1  _ 

i 

<  term> 

-i 

1 

J  . 

i 

<  factor > 

1 

! 

2 

<id> 

1 

1 

■ - - 

< idhead^ 


-I- 


'■  idtai  1  > 


i  n 


1 


<letter> 


NIL 


1 


^r 

<idtailel>  <idtail> 


4- 


NIL 


<dlglt> 


NIL 


1 


The  variable  ’'polynom"  has  the  following  content  after  the  first  run  through  the  loop 


polynom: 


<idtailel>  < idta 

±L> 

1  L 

2  ft 

NIL 

o 

<digit> 


After  the  second  loop  it  has  the  following  content  : 


polynom : 


<idtail> 

H:pz] 

<idtallel>  < id tail > 

2  m-EE 

<  d  i  g  i  t  > 


1  MIL 


l! 
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One  can  see  how  these  structures  represent  a  derivation  tree  and  how  the  GTREE  -  Ob¬ 
jects  which  correspond  to  the  generating  expressions  are  used  in  a  recursive  manner. 
A  pure  ALGOL-68  program  corresponding  to  the  above  program  could  be  generated  by  a 
translator  as  follows  : 

BEGIN 

INT  grad;  read(grad); 

SUBTREE  polynom  :=  (gen3\  NIL); 

FOR  i  TO  grad 
DO 

REF  []  SUBTREE  h  =  HEAP  [1:2]  SUBTREE; 
h[l]  :=  cterm  polynom; 
h[2]  :=  idt  i; 
polynom  :=  (genl,  h) 

OD; 

genprint(polynom)  co  output  of  the  string  which  is  described  by  the  tree  co 
END 

It  is  clear  that  the  generation  of  trees  at  runtime  is  done  by  setting  pointers,  no  expen¬ 
sive  tree  copying  is  necessary.  The  root  inspections  remain  reasonably  simple,  for  ex¬ 
ample  the  expression 
ROOT  term  INTO  (  factor,  termhrfactorh  )  , 
where  the  declarations 

FACTOR  factor;  TERM  term;  TERMH  termh;  FACTORH  factorh 
are  assumed,,  leads  to  the  execution  of  the  following  sequence  of  statements  (we  use 
the  ;:=  -  assignment  operator  for  UNION  -  values  from  the  old  version  of  ALGOL-68 
although  it  has  been  deleted  in  the  revised  one  [18])  ; 

BEGIN 

t  ::=  tree  OF  term;  co  tree  OF  term  is  always  a  NORMNODE  -  value  co 
st  :=  subtree  OF  term; 
nr  :=  pnr  OF  t; 
sons  :=  sons  OF  t; 

CASE  nr 
IN 

factor  :=  hproc(  sons[l]  ), 

termh  :=  hproc(  sons[l]  );  factorh  :=  hproc(  sons[2]  ) 

ESAC; 

nr 

END, 

where  the  following  system  identifiers  are  declared  globally  : 
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NORMNODE  t;  REF  []  SUBTREE  st;  INT  nr;  REF  []  CTREE  sons; 

PROC  hproc  =  (  REF  GTREE  son  )  SUBTREE  : 

BEGIN 
INT  i; 

IF  i  ::=  son  co  yields  true  if  son  is  an  INT  value,  in  this  case  this 

value  is  assigned  to  i.  Yields  false  otherwise 
without  any  assignment  co 
THEN  st[i]  co  go  to  a  new  tree  co 
ELSE  (son.st)  co  follow  the  old  tree  co 
FI 
END 

Many  of  these  operations  can  be  done  at  compile  time,  no  index  checks  are  necessary 
at  run  time.  The  global  variables  t,  st,  nr  and  sons  should  be  kept  in  registers  as  much 
as  possible  and  hproc  should  be  inserted  as  an  inline  -  routine  (macro)  if  space  restric¬ 
tions  allow  the  involved  space  overhead. 

Using  as  little  storage  as  possible,  an  object  of  type  GTREE  can  be  represented  in  a  16- 
bit  word  as  follows  : 

1. )  First  UNION  -  Alternative  : 

It)  j  Index  HI 

2. )  Second  UNION  -  Alternative  : 

H 

1  1  sons  1  pnr 

Values  of  type  SUBTREE  can  be  stored  in  2  words  because  the  length  of  the  subtrees  - 
array  need  not  be  stored  because  index  overflows  are  not  possible. 


A2.  Parsing  and  Translation  of  Generating  Expressions 

Assume  G  =  (Vff.Vr.P,  <S> )  is  a  reduced  generating  grammar  with  operator  insertion, 
and  assume  h  is  the  G  -  operator-eraser  according  to  Def.  1.  We  assume  that  the  gram¬ 
mar  h(G)  is  LR(k)  for  a  particular  k  and  card(R)  =  card(h(R))  .  According  to  Criterion  1, 
G  allows  an  unambiguous  operator  insertion. 

Assume  Cgen  is  an  LR(k)  syntax  checker  according  to  h(G).  We  assume  that  Cgen  works 
as  a  coroutine  which  is  reactivated  when  the  next  input  symbol  is  available,  and  we  as¬ 
sume  that  the  start  symbol  of  the  grammar  is  an  input  parameter  for  Cgen. 

Assume  Cgxpr  is  an  analyzing  program  which  analyzes  ALGOL-68  expressions  syntactical¬ 
ly  and  semantically  and  which  gives  as  a  result  the  mode  (i.e.  data  type)  of  the 
corresponding  value. 

Assume  nextsymbol  is  a  routine  which  scans  the  input  and  delivers  the  next  input  sym- 
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bol.  An  analyzing  program  for  generating  expressions  can  be  visualized  roughly  as  fol¬ 
lows  : 
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The  automatic  insertion  of  operators  can  be  done  within  Cgen  as  follows  :  Parallel  to  the 
generation  of  a  derivation 
<A  >  ->  f3\  fir' 

according  to  h(G)  a  derivation 
<A  >  -*  jffj  •  •  •  -*  (3r 

is  constructed  where  /?i eh~((3i),  •  •  *  ,  {ZrEh~({ir')  . 

Each  step  is  constructed  as  follows  :  If  in  the  first  derivation  a  production 
<Aj>  ::=  t  e  h(R) 

is  used,  we  use  the  uniquely  defined  production 
<Aj>  ::=  7  where  7  e  h~(r) 

in  the  second  derivation.  This  production  is  uniquely  defined  because  we  have  card(R)  = 
card(h(R)).  This  means  we  insert  the  operators  step  by  step  when  we  construct  the 
derivation. 

Normally,  it  is  not  necessary  to  store  the  derivations  explicitly,  but  the  compiler  has  to 
generate  corresponding  GTREE  -  Objects  and  it  has  to  generate  a  corresponding 
machine  program  the  structure  of  which  has  been  outlined  in  chapter  1.  All  these  com¬ 
piler  operations  can  be  generated  automatically  from  the  generating  grammar. 

Several  remarks  seem  to  be  appropriate  : 

a. )  If  a  one-pass  compiler  is  used,  difficulties  might  arise.  Consider  for  example  the  fol¬ 
lowing  generating  grammar  : 

<A>  ::=  [opl  :  B  ->  C}  £op2  :  B  ->  D}  a  | 

|op3  :  B  ->  E]  $op4 :  B  ->  F$  b 

<B>  ::= 

<C>  ::= 

<D>  ::= 

<E>  ::= 

<F>  ::= 

and  the  generating  expression 
A  GEN  $bl$  $b2j  a  NEG  (bl,  b2  are  of  type  B)  . 

The  operator  insertion  has  to  be  delayed  until  the  symbol  "a"  is  read.  In  this  case,  if  a 
one-pass  compiler  is  considered,  the  operator  insertion  can  be  handled  similar  to 
forward-jumps  in  conventional  compilers  for  conventional  languages,  i.e.  by  using  an 
auxiliary  table  or  by  inserting  the  operators  afterwards. 

b. )  In  general,  several  operator  calls  are  identical,  so  optimization  by  using  standard 
techniques  is  advisable 

For  reading  values  of  the  new  types,  the  syntax  checker  Cgen  can  be  used  directly,  the 
same  is  true  for  new  operators  which  are  defined  by  COP  -  Declarations.  In  order  to  im¬ 
prove  efficiency,  a  manual  implementation  is  in  some  cases  advisable,  for  example  the 
idt  -  Operator  mentioned  in  chapter  2  doesn’t  need  a  sophisticated  syntax  checker,  it 
has  only  to  make  sure  that  the  input  value  is  not  negative. 
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Normally,  explicit  trees  are  not  needed  for  all  data  types.  For  example,  for  identifiers 
the  derivation  trees  are  normally  not  of  interest.  It  is  possible  to  allow  special  instruc¬ 
tions  in  addition  to  the  generating  grammar  for  staling  this.  The  implementation  can 
use  this  information  and  store  only  strings  and  leave  the  corresponding  trees  out 
where  applicable. 
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Abstract 

This  paper  is  a  continuation  of  a  previous  paper.  It  gives  some  language  tools  for  gen¬ 
erating  lists  in  a  descriptive  manner.  Tools  for  traversing  corresponding  derivation 
trees  are  described  as  well. 


1 .  Introduction 


This  paper  is  a  continuation  of  [2],  a  familiarity  with  [2]  is  assumed.  The  same  nota¬ 
tions  as  in  [2]  are  used. 

Conventional  programming  languages  often  have  list  structures  at  various  syntactical 
positions,  for  example  index  lists  for  array  applications,  lists  of  statements,  lists  of  de¬ 
clarations  and  so  on.  Even  the  simple  programming  language  mentioned  in  the  intro¬ 
duction  of  [2]  contains  lists:  The  sequence  of  terms  which  forms  an  expression  can  be 
viewed  as  a  list.  If  we  want  to  generate  a  list  using  the  tools  described  so  far  in  [2],  we 
have  to  generate  it  step  by  step,  for  example  the  expression 
a.c  +  '  1  '  +  an 

could  be  generated  as  follows  ,  where  the  generating  grammar  from  example  1  in 
chapter  4  in  [2]  is  assumed  : 

BEGIN 

1NT  n;  read(n); 

EXPR  e  :=  GEN  aO  NEG; 

FOR  i  TO  n 
DO 

e  :=  GEN  [e]  +  NEG 
OD; 

print(e) 

END  . 

It  would  be  much  more  comfortable  and  much  more  readable  for  the  programmer  if  he 
could  generate  lists  in  a  more  descriptive  manner,  for  example  by  writing 
e  :=  GEN  a|0$  +  ...  +  a$nj  NEG  . 
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Another  example  of  a  list  is  contained  in  the  third  example  in  chapter  4  in  [2],  namely 
the  indexlist  ij,  ....  ik.  It  would  be  nice  if  the  programmer  could  just  write 
il  :=  GEN  i[l] . i\k]  NEG 

instead  of  performing  the  job  by  writing  a  loop.  The  purpose  of  this  paper  is  to  develop 
language  tools  for  generating  lists  in  such  a  descriptive  manner. 


2.  Language  tools  for  generating  lists  in  a  more  descriptive  manner 

At  first  we  augment  the  notion  of  generating  grammars  with  operator  insertion  by  pro¬ 
ductions  of  the  following  form,  where  we  assume  that  the  symbol  is  not  a  valid  sym¬ 
bol  in  the  language  which  we  want  to  describe  : 

<A>  ::=  <B>  a  ...  cr  <B> 

where  cr  is  a  (possibly  empty)  sequence  of  terminal  symbols  of  the  grammar,  cr  is 
called  separator.  <A>  and  <B>  are  nonterminal  symbols.  Those  productions  are  called 
list  productions.  In  addition,  if  there  is  a  production  of  the  above  form  for  the  nonter¬ 
minal  <A>,  this  has  to  be  the  only  production  for  <A>.  This  restriction  allows  to  refer  to 
a  list  production  by  using  the  name  of  the  nonterminal  symbol  on  the  left  hand  side  of 
the  production.  For  example,  the  production 
<A>  <indexlistel>,  ....  <indexlistel> 
is  a  list  production. 

A  grammar  with  productions  like  that  is  called  generating  grammar  with  list  produc¬ 
tions. 

Example  1 : 

We  augment  the  generating  grammar  in  the  third  example  of  chapter  4  in  [2]  by  the 
following  productions  : 

<stmtlist>  ::=  <stmtlist>;  <stmtdesc>  {  <stmtdesc> 

<stmtdesc>  <stmt>;  ...;  <stmt> 

<indcxlist>  ::=  <indexlist>,<indexdesc>  |  <indexdesc> 

<indexdesc>  =  <indexlistel>,  ....  <indexlistel> 

Obviously,  we  cannot  allow  every  generating  expression  which  is  possible  if  w*e  view  a 
generating  grammar  with  list  productions  as  an  ordinary  generating  grammar.  For  ex¬ 
ample,  the  generating  expression 
INDEXLIST  GEN  ijlHlj . i|2|(k]  NEG 

is  meaningless  because  it  is  not  clear  how  many  elements  the  list  should  have  and  how 
the  list  elements  are  formed.  The  generating  expression 
INDEXLIST  GEN  i . i  NEG 

is  meaningless  as  weli  because  we  don’t  know  either  how  many  elements  the  list  should 
have.  But  the  expression 
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INDEXLIST  GEN  i|  1],  ...,  ijkj  NEG 

is  meaningful.  As  we  will  see  later,  it  describes  exactly  a  list  of  the  form 
'i  i>  ■  •  •  >  ik 

where  k  is  an  INT  -  variable  which  must  be  declared  in  the  scope  of  the  generating  ex¬ 
pression.  The  sequence 
i\l],  ....  i|k) 

is  called  a  valid  list  description.  The  following  algorithm  rejects  generating  expressions 
with  invalid  list  descriptions  : 

Let  Gg  be  the  following  grammar  : 


<sexpr> 

<prim> 

<addop> 

<number> 

<id> 

<digit> 

<letter> 


::=  <sexpr>  <addop>  <prim>  j  <prim> 

::=  <addop>  <prim>  !  <number>  |  <id>  |  (  <sexpr>  ) 

::=  +  I  - 

::=  <number>  <digit>  |  <digit> 

<id>  <letter>  |  <id>  <digit>  |  <letter> 

0  |  1  |  2  i  3  |  4  j  5  j  6  {  7  |  8  (  9 

::=  a  |  b  |  c  |  ...  1  z 


Obviously,  Gg  describes  arithmetic  expressions  where  +  and  -  are  the  only  operators. 
Let  g  be  a  generating  expression  with  list  descriptions.  The  algorithm  examines  all  list 
descriptions  7  =  a  a  •  •  *  ct  0  where  cr  is  the  delimiter  string  as  follows  : 

a. )  a  and  /S  must  have  the  following  form  : 

P  =  Qiifilgzifz]  •••  gk\fk]9k+i 
where  e  j  *  *  fk  for  k  S  1. 

That  means  :  the  k  positions  in  {  and  j  are  the  only  positions  where  a  and  differ,  and 
there  must  be  at  least  one  such  position. 

b. )  e*  ,  fi  (i=l,...,k)  must  satisfy  one  of  the  following  conditions: 

e*  =  a[e*']  and  =  c z  [/*’],  where  a  is  an  array  identifier,  or 

ei  =  r(ei')  and  =  ?-(/*’)  where  r  is  a  procedure  identifier,  or 

e<  =  et'  and  /t  =  /*' 

where  e s  L(Gjr)  and  /$'  e  L{Ge)  and  both  contain  only  identifiers  which  can  deliver 
values  of  type  INT,  i.e.  which  are  declared  outside  of  the  generating  expression  of  type 
REF  j  INT  for  a  j  s  0. 

c. )  The  expressions 

(/ i  )—(e  1)1 ....  C/VM?*') 

must  be  formally  equivalent  which  means  that  they  deliver  the  same  value  for  indepen¬ 
dent  assignments  of  values  to  the  names  in  the  expressions.  Deciding  the  formal 
equivalence  by  using  normal  form  expressions  is  straightforward,  see  for  ex.  [l]. 

Now  we  must  define  how  a  generating  expression  with  list  descriptions  is  evaluated  :  It 
is  evaluated  similar  to  a  normal  generating  expression  except  that  a  valid  list  expres¬ 
sion  7  =  a  a  ■  •  ■  a  (3  delivers  a  subtree  as  follows  : 
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1 1  (7  1 2  d  1  '  '  ti 

where  1  is  the  value  of  (/*’)  -  (e*')  +  1,  where  /$'  and  e*'  are  defined  as  in  the  algorithm 
above,  and  t  are  subtrees  corresponding  to  a  where  the  expressions  e{t  ,  .  .  ,  e*.' 

are  evaluated  and  incremented  by  one  from  left  to  right  resp. 

Example  2: 


Assuming  the  generating  grammar  with  list  productions  from  example  1,  the  following 
piece  of  program  is  correct  : 

BEGIN 

INT  k;  read(k); 

STMTLIST  stl; 

stl  :=  GEN  a  +  b[  i{  1  j,  ....  i$k}  ]  NEG; 
print(stl) 

END  . 

For  k=5,  the  string  il,i2,i3,i4,i5  is  printed,  and  the  varable  stl  contains  the  tree  : 
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The  example  program  in  example  3  in  chapter  4  in  [2]  can  be  written  as  follows  : 

BEGIN 

STMTLIST  st;  INT  k;  read(k); 

co  generate  the  nested  loops  co 

st  :=  GEN  h[kj  :=  h$kj*xfk}  +  a[  i[l}t  ....  i$kj  ]  NEG; 

FOR  j  FROM  k  BY -1  TO  2 
DO 

st  :=  GEN 

h|j|  :=  0; 

FOR  i(j]  FROM  0  BY  1  TO  n|j] 

DO 

1st} 

OD; 

h$j-l}  :=  h$i-l}*xfj-l}  +  h\]\ 

NEG 
OD;  ‘ 
st  :=  GEN 

hi  :=  0; 

FOR  it  FROM  0  BY  1  TO  nl 
DO 
jstj 
OD; 
hi 

NEG; 

print(st) 

END  . 

In  order  to  traverse  trees,  we  need  another  tool  for  traversing  lists  in  addition  to  ROOT 
-  inspections.  This  is  the  newly  introduced  operator  list.  Valid  calls  of  this  operator  look 
like 

a  list  b 

where  a  is  a  variable  of  type  A  associated  with  the  nonterminal  <A>,  b  is  a  variable  of 
type  B  associated  with  the  nonterminal  <B>.  The  call  is  valid  if  there  is  a  production 
<B>  ::=  <A>  cr ...  cr  <A> 

in  the  underlying  grammar.  It  works  as  follows  :  It  is  assumed  that  variables  of  type  B 
contain  an  internal  pointer  which  points  to  one  <A>  -  subtree  at  a  time  or  is  empty. 
This  pointer  is  set  to  the  first  subtree  if  a  value  is  assigned  to  the  variable  by  means  of 
a  ROOT  inspection  or  the  list  -  operator.  The  call  a  list  b  then  works  as  follows  : 

a. )  The  pointer  is  empty  : 

The  operator  delivers  the  value  FALSE,  no  assignments  are  made. 

b. )  The  pointer  is  not  empty  : 
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The  <A>  -  subtree  to  which  the  pointer  points  is  assigned  to  the  variable  a.  The  pointer 

in  the  variable  b  is  changed  as  follows  : 

a.)  the  current  subtree  is  not  the  rightmost  subtree  : 

the  new  pointer  points  to  the  <A>  -  subtree  to  the  right  of  the  subtree  to  which  the 
pointer  currently  points. 

/?.)  the  current  subtree  is  the  rightmost  subtree  :  the  pointer  is  emptied 
In  both  cases  a  and  /?,  the  result  of  the  operator  call  is  TRUE. 

This  definition  makes  clear  why  we  made  the  restriction  that  if  there  is  a  list  produc¬ 
tion  for  a  nonterminal  <A>,  this  production  has  to  be  the  only  production  for  <A>,  be¬ 
cause  otherwise  ROOT  -  inspections  and  the  list  -  operator  could  be  mixed  up,  thus 
violating  the  principle  of  static  types. 

The  implementation  of  list  descriptions  and  the  list  -  operator  is  straightforward. 

In  [l],  the  concept  of  more  descriptive  language  tools  is  more  general,  using  macro 
techniques.  But  generating  list  structures  is  the  most  important  part  and  the  concepts 
are  easier  to  understand,  so  we  restricted  ourselves  to  this  simple  case. 
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Glenn  F.  Stewart,  September  1974 
[M.Sc.  Thesis,  DCS,  1974] 

*  CSRG-40  EDUCATIONAL  DATA  BASE  SYSTEM  USER’S  MANUAL, 

J.  KlebanofT,  F.  Lochovsky,  A.  Rozitis,  and 

D.  Tsichritzis,  September  1974 

*  CSRG-41  NOTES  FROM  A  WORKSHOP  ON  THE  ATTAINMENT  01' 

RELIABLE  SOFTWARE 

David  B.  Wortman  (ed.),  September  1974 

*  CSRG-42  THE  PROJECT  SUE  SYSTEM  LANGUAGE  REFERENCE  MANUAL 

B.L.  Clark  and  F.J.B.  Ham,  September  1974 

*  CSRG-43  A  DATA  BASE  PROCESSOR 

E. A.  Ozkarahan,  S.A.  Schuster  and  K.C.  Smith, 

November  1974  [Proceedings  National  Computer 
Conference  1975,  v.44,  pp. 379-388] 

*  CSRG-44  MATCHING  PROGRAM  AND  DATA  REPRESENTATION  TO  A 

COMPUTING  ENVIRONMENT 
Eric  C.R.  Hehner,  Novemver  1974 
[Ph.D.  Thesis,  DCS,  1974] 

See  Computer,  Vol.9,  No. 9,  August  1976,  pp. 65-70. 

*  CSRG-45  THREE  APPROACHES  TO  RELIABLE  SOFTWARE;  LANGUAGE  DESIGN, 

DYADIC  SPECIFICATIONS,  COMPLEMENTARY  SEMANTICS 
J.E.  Donahue,  J.D.  Gannon,  J.V.  Guttag  and 
J.J.  Horning,  December  1974 

CSRG-46  THE  SYNTHESIS  OF  OPTIMAL  DECISION  TREES  FROM 
DECISION  TABLES 

Helmut  Schumacher,  December  1974 

[M.Sc.  Thesis,  DCS,  1974;  CACM,  v.19,  n.6,  June  1976] 

*  CSRG-47  LANGUAGE  DESIGN  TO  ENHANCE  PROGRAMMING  RELIABILITY 

John  D.  Gannon,  January  1975 
[Ph.D.  Thesis,  DCS,  1975] 

*  CSRG-48  DETERMINISTIC  LEFT  TO  RIGHT  PARSING 

Christopher  J.M.  Turnbull,  January  1975 
[Ph.D.  Thesis,  EE,  1974] 

*  CSRG-49  A  NETWORK  FRAMEWORK  FOR  RELATIONAL  IMPLEMENTATION 

D.  Tsichritzis,  February  1975  [in  Data  Base  Description, 

Dongue  and  Nijssen  (eds.),  North  Holland  Publishing  Co.] 
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*  CSRG-50  A  UNIFIED  APPROACH  TO  FUNCTIONAL  DEPENDENCIES 

AND  RELATIONS 

P.A.  Bernstein,  J.R.  Swenson  and  D.C.  Tsichritzis 
February  1975  [Proceedings  of  the  ACM  SIGMOD 
Conference,  1975] 

*  CSRG-51  ZETA:  A  PROTOTYPE  RELATIONAL  DATA  BASE  MANAGEMENT  SYSTEM 

M.  Brodie  (ed).  February  1975  [Proceedings  Pacific  ACM 
Conference,  1975] 

*  CSRG-52  AUTOMATIC  GENERATION  OF  SYNTAX-REPAIRING  AND 

PARAGRAPHING  PARSERS 
David  T.  Barnard,  March  1975 
[M.Sc.  Thesis,  DCS,  1975] 

*  CSRG-53  QUERY  EXECUTION  AND  INDEX  SELECTION  FOR  RELATIONAL 

DATA  BASES 

J.H.  Gilles  Farley  and  Stewart  A.  Schuster,  March  1975 

CSRG-54  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

J.V.  Guttag  (ed.),  Third  Edition,  April  1975 

CSRG-55  STRUCTURED  SUBSETS  OF  THE  PL/1  LANGUAGE 

Richard  C.  Holt  and  David  B.  Wortman,  May  1975 

*  CSRG-56  FEATURES  OF  A  CONCEPTUAL  SCHEMA 

D.  Tsichritzis,  June  1975  [Proceedings  Very  Large 
Data  Base  Conference,  1975] 

*  CSRG-57  MERLIN:  TOWARDS  AN  IDEAL  PROGRAMMING  LANGUAGE 

Eric  C.R.  Hehner,  July  1975 

see  Acta  Informatica  Col. 10,  No. 3,  pp. 229-243,  1978 

CSRG-58  ON  THE  SEMANTICS  OF  THE  RELATIONAL  DATA  MODEL 
Hans  Albrecht  Schmid  and  J.  Richard  Swenson, 

July  1975  [Proceedings  of  the  ACM  SIGMOD  Conference,  1975] 

*  CSRG-59  THE  SPECIFICATION  AND  APPLICATION  TO  PROGRAMMING 

OF  ABSTRACT  DATA  TYPES 
John  V.  Guttag,  September  1975 
[Ph.D.  Thesis,  DCS,  1975] 

*  CSRG-60  NORMALIZATION  AND  FUNCTIONAL  DEPENDENCIES  IN  THE 

RELATIONAL  DATA  BASE  MODEL 
Phillip  Alan  Bernstein,  October  1975 
[Ph.D.  Thesis,  DCS,  1975] 

*  CSRG-61  LSL:  A  LINK  AND  SELECTION  LANGUAGE 

D.  Tsichritzis,  November  1975  [Proceedings  ACM 
SIGMOD  Conference,  1976] 
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*  CSRG-62  COMPLEMENTARY  DEFINITIONS  OF  PROGRAMMING  LANGUAGE 

SEMANTICS 

James  E.  Donahue,  November  1975 
[Ph.D.  Thesis,  DCS,  1975] 

CSRG-63  AN  EXPERIMENTAL  EVALUATION  OF  CHESS  PLAYING  HEURISTICS 
Lazio  Sugar,  December  1975 
[M.Sc.  Thesis,  DCS,  1975] 

CSRG-64  A  VIRTUAL  MEMORY  SYSTEM  FOR  A  RELATIONAL  ASSOCIATIVE 
PROCESSOR 

S.A.  Schuster,  E.A.  Ozkarahan,  and  K.C.  Smith, 

February  1976  [Proceedings  National  Computer 
Conference  1976,  v.45,  pp. 855-862] 

CSRG-85  PERFORMANCE  EVALUATION  OF  A  RELATIONAL  ASSOCIATIVE 
PROCESSOR 

E.A.  Ozkarahan,  S.A.  Schuster,  and  K.C.  Sevcik, 

February  1976  [ACM  Transactions  on  Database 
Systems,  v.  1,  n:4,  December  1976] 

CSRG-66  EDITING  COMPUTER  ANIMATED  FILM 
Michael  D.  Tilson,  February  1976 
[M.Sc.  Thesis,  DCS,  1975] 

CSRG-67  A  DIAGRAMMATIC  APPROACH  TO  PROGRAMMING  LANGUAGE 
SEMANTICS 

James  R.  Cordy,  March  1976 
[M.Sc.  Thesis,  DCS,  1976] 

*  CSRG-68  A  SYNTHETIC  ENGLISH  QUERY  LANGUAGE  FOR  A  RELATIONAL 

ASSOCIATIVE  PROCESSOR 

L.  Kerschberg,  E.A.  Ozkarahan,  and  J.E.S.  Pacheco, 

April  1976 

CSRG-69  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

D.  Barnard  and  D.  Thompson  (eds.),  Fourth  Edition, 

May  1976 

*  CSRG-70  A  TAXONOMY  OF  DATA  MODELS 

L.  Kerschberg,  A.  Klug,  and  D.Tsichritzis,  May  1976 
[Proceedings  Very  Large  Data  Base  Conference,  1978] 

*  CSRG-71  OPTIMIZATION  FEATURES  FOR  THE  ARCHITECTURE  OF  A 

DATA  BASE  MACHINE 

E. A.  Ozkarahan  and  K.C.  Sevcik,  May  1976 

[ACM  Transactions  of  Database  Systems,  v.2,  n.4,  December  1977] 

*  CSRG-72  THE  RELATIONAL  DATA  BASE  SYSTEM  OMEGA  -  PROGRESS  REPORT 

H.A.  Schmid  (ed.),  P.A.  Bernstein  (ed.),  B.  Arlow, 

R.  Baker  and  S.  Pozgaj,  July  1976 
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CSRG-73  AN  ALGORITHMIC  APPROACH  TO  NORMALIZATION  OF 
RELATIONAL  DATA  BASE  SCHEMAS 
P.A  Bernstein  and  C.  Beeri,  September  1976 

*  CSRG-74  A  HIGH-LEVEL  MACHINE-ORIENTED  ASSEMBLER  LANGUAGE 
FOR  A  DATA  BASE  MACHINE 

E.A.  Ozkarahan  and  S.A.  Schuster,  October  1976 

CSRG-75  DO  CONSIDERED  OD:  A  CONTRIBUTION  TO  THE  PROGRAMMING 
CALCULUS 

Eric  C.R.  Hehner,  November  1976 
Acta  Informatica  to  appear  1979 

CSRG-76  SOFTWARE  HUT:  A  COMPUTER  PROGRAM  ENGINEERING 
PROJECT  IN  THE  FORM  OF  A  GAME 
J.J.  Horning  and  D.B.  Wortman,  November  1976 

[IEEE  Transactions  on  Software  Engineering,  v.SE-3,  n.4,  July  1977] 

CSRG-77  A  SHORT  STUDY  OF  PROGRAM  AND  MEMORY  POLICY  BEHAVIOUR 
G.  Scott  Graham,  January  1977 

CSRG-7B  A  PANACHE  OF  DBMS  IDEAS 

D.  Tsichritzis  (ed.),  February  1977 

CSRG-79  THE  DESIGN  AND  IMPLEMENTATION  OF  AN  ADVANCED  LA.LR 
PARSE  TABLE  CONSTRUCTOR 
David  H.  Thompson,  April  1977 
[M.Sc.  Thesis.  DCS,  1976] 

CSRG-80  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

D.  Barnard  (ed.),  Fifth  Edition,  May  1977 

CSRG-81  PROGRAMMING  METHODOLOGY:  AN  ANNOTATED  BIBLIOGRAPHY 
FOR  IFIP  WORKING  GROUP  3.3 

Sol  J.  Greenspan  and  J.J.  Horning  (eds.),  First  Edition,  May  1977 
CSRG-82  NOTES  ON  EUCLID 

edited  by  W.  David  Elliot  and  David  T.  Barnard,  August  1977 

CSRG-83  TOPICS  IN  QUEUEING  NETWORK  MODELING 
edited  by  G.  Scott  Graham,  July  1977 

CSRG-84  TOWARD  PROGRAM  ILLUSTRATION 

Edward  Yarwood,  September  1977 
[M.Sc.  Thesis,  DCS,  1974] 

CSRG-85  CHARACTERIZING  SERVICE  TIME  AND  RESPONSE  TIME 

DISTRIBUTIONS  IN  QUEUEING  NETWORK  MODELS  OF  COMPUTER 
SYSTEMS 

Edward  D.  Lazowska,  September  1977 
[Ph.D.  Thesis.  DCS,  1977] 
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CSRG-86  MEASUREMENTS  OF  COMPUTER  SYSTEMS  FOR  QUEUEING 
NETWORK  MODELS 
Martin  G.  Kienzle,  October  1977 

[M.Sc.  Thesis,  DCS,  1977;  Proc.  Int.  Symp.  on  Modelling  and  Performance 
Evaluation  of  Computer  Systems,  Vienna,  1979] 

CSRG-87  ’OLGA’  LANGUAGE  REFERENCE  MANUAL 

B.  Abourbih,  H.  Trickey,  D.M.  Lewis,  E.S.  Lee, 

P.I.P.  Boulton,  November  1977 

CSRG-88  USING  A  GRAMMATICAL  FORMALISM  AS  A  PROGRAMMING  LANGUAGE 
Brad  A.  Silverberg,  January  1978 
[M.Sc.  Thesis.  DCS,  1978] 

CSRG-89  ON  THE  IMPLEMENTATION  OF  RELATIONS:  A  KEY  TO  EFFICIENCY 
Joachim  W.  Schmidt.  January  1978 

CSRG-90  DATA  BASE  MANAGEMENT  SYSTEM  USER  PERFORMANCE 
Frederick  H.  Lochovsky,  April  1978 
[Ph.D.  Thesis,  DCS,  1978] 

CSRG-91  SPECIFICATION  AND  VERIFICATION  OF  DATA  BASE 
SEMANTIC  INTEGRITY 
Michael  Lawrence  Brodie,  April  1978 
[Ph.D.  Thesis,  DCS,  1978] 

CSRG-92  STRUCTURED  SOUND  SYNTHESIS  PROJECT  (SSSP): 

AN  INTRODUCTION 

by  William  Buxton.  Guy  Fedorkow,  with  Ronald  Baecker, 

Gustav  Ciamaga,  Leslie  Mezei  and  K.C.  Smith,  June  1978 

CSRG-93  A  DEVICE-INDEPENDENT. GENERAL-PURPOSE  GRAPHICS  SYSTEM 
IN  A  MINICOMPUTER  TIME-SHARING  ENVIRONMENT 
William  T.  Reeves,  August  1978 
[M.Sc.  Thesis.  DCS,  1976] 

CSRG-94  ON  THE  AXIOMATIC  VERIFICATION  OF 
CONCURRENT  ALGORITHMS 
Christian  Lengauer,  August  1978 
[M.Sc.  Thesis,  DCS,  1978] 

CSRG-95  PISA:  A  PROGRAMMING  SYSTEM  FOR  INTERACTIVE 
PRODUCTION  OF  APPLICATION  SOFTWARE 
Rudolf  Marty,  August  1978 

CSRG-96  ADAPTIVE  MICROPROGRAMMING  AND  PROCESSOR  MODELING 
Walter  G.  Rosocha 
[Ph.D.  Thesis,  EE,  August  1978] 

CSRG-97  DESIGN  ISSUES  IN  THE  FOUNDATION  OF  A  COMPUTER-BASED 
TOOL  FOR  MUSIC  COMPOSITION 
William  Buxton 

[M.Sc.  Thesis.  CSRG,  October  1978] 
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CSRG-98  THEORY  OF  DATABASE  MAPPINGS 
Anthony  C.  Klug 

[Ph.D.  Thesis,  DCS,  December  1978] 

CSRG-99  HIERARCHICAL  COROUTINES:  A  MECHANISM  FOR  IMPROVED 
PROGRAM  STRUCTURE 
Leonard  I.  Vanek,  February  1979 

CSRG-100  TOPICS  IN  PERFORMANCE  EVALUATION 
G.  Scott  Graham  (ed.),  July  1979 

CSRG-101  A  PANACHE  OF  DBMS  IDEAS  II 

F.H.  Lochovsky  (ed.),  May  1979 

CSRG-102  A  SIMPLE  SET  THEORY  FOR  COMPUTING  SCIENCE 
Eric  C.R.  Hehner,  May  1979 

CSRG-103  THE  CENTRALIZED  ALGORITHM  IN  DISTRIBUTED  SYSTEMS 
Ernest  J.H.  Chang 
[Ph.D.  Thesis,  DCS,  July  1979] 

CSRG-104  ELIMINATING  THE  VARIABLE  FROM  DIJKSTRA'S 
MINI-LANGUAGE 
D.  Hugh  Redelmeier,  July  1979 

CSRG-105  A  LANGUAGE  FACILITY  FOR  DESIGNING  INTERACTIVE 
DATABASE-INTENSIVE  APPLICATIONS 
John  Mylopoulos,  Philip  A.  Bernstein,  Harry  K.T.  Wong, 
July  1979 

CSRG-106  ON  APPROXIMATE  SOLUTION  TECHNIQUES  FOR 

QUEUEING  NETWORK  MODELS  OF  COMPUTER  SYSTEMS 
Satish  Kumar  Tripathi,  July  1979 

CSRG-107  A  FRAMEWORK  FOR  VISUAL  MOTION  UNDERSTANDING 
John  K.  Tsotsos,  John  Mylopoulos,  H.  Dominic  Cowey 
Steven  W.  Zucker,  DCS,  June  1979 

CSRG-108  DIALOGUE  ORGANIZATION  AND  STRUCTURE  FOR 
INTERACTIVE  INFORMATION  SYSTEMS 
John  Leonard  Barron 
[M.Sc.  Thesis,  DCS,  1980] 

CSRG-109  A  UNIFYING  MODEL  OF  PHYSICAL  DATABASES 
D.S.  Batory,  C.C.  Gotlieb,  April  1980 

CSRG-1 10  OPTIMAL  FILE  DESIGNS  AND  REORGANIZATION  POINTS 
D.S.  Batory,  April  1980 

CSRG-1 11  A  PANACHE  OF  DBMS  IDEAS  III 
D.  Tsichritzis  (ed.),  April  1980 
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CSRG-1 12  TOPICS  IN  PSN  -  II:  EXCEPTIONAL  CONDITION 

HANDLING  IN  PSN;  REPRESENTING  PROGRAMS  IN  PSN; 
CONTENTS  IN  PSN 

Yves  Lesperance,  Byran  M.  Kramer,  Peter  F.  Schneider 
April,  1980 

CSRG-113  SYSTEM-ORIENTED  MACRO-SCHEDULING 
C.C.  Gotlieb  and  A.  Schonbach 
May  1980 

CSRG-1 14  A  FRAMEWORK  FOR  VISUAL  MOTION  UNDERSTANDING 
John  Konstantine  Tsotsos 
[Ph.D.  Thesis,  DCS,  June  1980] 

CSRG-1 15  SPECIFICATION  OF  CONCURRENT  EUCLID 
James  R.  Cordy  and  Richard  C.  Holt 
July  1980 

CSRG-1 16  THE  REPRESENTATION  OF  PROGRAMS  IN  THE 

PROCEDURAL  SEMANTIC  NETWORK  FORMALISM 

Bryan  M.  Kramer 

[M.Sc.  Thesis,  DCS,  1980] 

CSRG-1 17  CONTEXT-FREE  GRAMMARS  AND  DERIVATION  TREES  AS 
PROGRAMMING  TOOLS 
Volker  Linnemann 
September  1980 
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